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Business Process Automation 

1 Related appucation Information 

[Oil This application claims priority to U.S. Provisional Application No. 60/477 757 filed 
June 12. 2003. entitled ««Business Process Automation", to Subhra Bose. St«ve 
Scimone. Nallan Sriraman. Anhur Bernstein. Philip C. Lewis, Radu Grosu. Ziyang 
Duan. the contents of which are hereby incorporated herein by reference in its 
entirety. 

2 FIELD OF THE INVENTION 

I02J Aspects of the present invention relate to software and business applications Moi^ 
particularly, aspects of the present invention relate to automating business 
applications. 

3 Background of the in\tention 

[031 A business process is a collaborative execution of business activities according to the 
specific business rules in order to achieve some business goals. Financial Services and 
other Businesses have put in a lot of eflfort into reengineering their business processes 
to lower cost and improve efficiency. Recentiy, with the help of tiie rapid 
advancement of computer and information technology, complex business processes in 
financial services and otiier industries can now be automated, tasks which were 
traditionally performed manually. This brings up many new challenges: 1) Business 
processes need to be easily created, deployed and updated. 2) Business processes 
needs to be constiixcted in an interoperable way, so that different organizations and 
departmente can integrate their business processes together. 3) Correctiaess and 
security of a business process needs to be guaranteed. 4) Tools are needed to fecilitate 
business process management and reusability. 

(041 XML has appeared as the new standard for data representation and exchange of the 
World Wide Web. More and more applications have been built based on XML to 
facilitate interoperability between different heterogeneous systems. XML-Schema has 
become a standard to specify semi-stiiictured data-types in XML. Much work has 
been done on miderstanding semi-stiuctured data types and their relationship with 
relational data. Web service protocols, such as SOAP. WSDL. and UDDI provides 
ubiquitous interoperability of services, and aUow coordination of highly distributed 
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services in a business process. Native XML databases are emerging on the market to 
provide XML data stores with query and update capabiHties. 



[OS] 



Workflow is known in the art and provides a way to separate the control logic from 
the system components, and specify the control logic at a high level. According to 
Workflow Management CoaUtion. workflows are computational models of business 
processes. Workflow systems are originally developed for office automation. Tbos^ 
systems are targeted for simple tasks such as document processing and file sharing 
men people have been considering more complex transactional workflows to model 
business process. Various extended transaction models, which are based on 
transaction models with relaxed atomicity and isolation, have a nice Aeoretical 
framework inherited from database transactions. However, few of them are 
implemented in commercial systems. The workflow model generalizes them, provides 
much broader functionality and is a more appropriate framework to address complex 
busmess processes. During the past few years, many commercial systems have been 
developed, such as Tibco's BPM. Microsoft's BizTalk. IBM's Exotica/FlowMark 
etc. Many research prototypes have been created, such as ConTract and Mentor etc' 
Many fonnal methods have been proposed for workflow modeling and execution- 
event algebra, state chart, peti net. temporal logic, transaction logic and etc XML 
based standards have been proposed to define and model workflows as interactions of 
web services, such as BPML. WSCL. WSCT. BPEL4WS. etc. 

[061 Rules engines have also been under development for years. Currently there are several 
standards and commercial systems that are provided by fflM, Microsoft. iLog 
Blazesoft and others. The rule engines can consume rule definitions and execute' 
different types of rules, such as validation rules, business policy rules and business 
decisions. There are different types of rule engines as well e.g. inference engines and 
decision tree engines. Business processes often contain multiple business rules 
Because most programming environments are designed for either data or procedures 
when confronted with a business specification written as a collection of rules the 
developer is faced witii a ti4cky problem. The rules camiot be expressed in data and 
coding them procedurally leads to "spaghetti code." Further, tiie original logical 
structure of the rules, which take a declarative form and are easy to understand get 
lost m the code, become difBcult to debug, and ahnost impossible to update if 
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necessary. There exist several emerging standards for rule descrn)tion. One such 
standard, namely RuleML is the canonical Web language for rules using XML 
markiq), formal semantics, and efficient implementations. RuleML covers ttie entire 
rule spectrum, from derivation rules to transformation rules to reaction rules. RuleML 
can Ihus specify queries and inferences in Web ontologies, mappings between Web 
ontologies, and dynamic Web behaviors of workflows, services, and agents. 

[07] State machines have been widely used for modeling reactive systems. The original 
finite-state machines have been extended to express hierarchy and concurrency, such 
as in Statechart. Many works have been done to define semantics and build modeling 
tools based on state machines. Software design languages and tools, such as UML, 
ROOM, and STATE-MATE, have employed variations of slate machines. Despite the 
existence of these technologies, problems still remain in business process automation 
and management. 

4 Summary 

[08] Aspects of the present invention provide a framework and methods that solve at least 
one of the above problems in business process automation and management. In this 
fiamework, business processes may be modeled as integration of flows, rules and 
state machines. XML and web service standards may be used as the basis to provide 
interoperability. Standard based declarative languages may be used for high level 
specification of a business process and its components; Specifications may be based 
on formal logical models so that automatic verification and model checking methods 
can be developed to guarantee correctness. Semantics may be formally defined and 
methods of semantic based verification and workflow syntiiesis are provided. 

[091 Aspects of the present invention propose an enhanced use of the flow, rule and state 
engines. A business process is specified in a declarative language such as XML which 
represents fbe control wifliin the business process, the externalized business rules and 
the states of the business entities. The relevant portions of the specification are 
executed in the flow, rules and state engines. Each of these engines provides specific 
computational aspects to flie execution environment described in at least one aspect of 
the invention. 
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110] The ability to describe iJie key constituents of a business process in a declarative 
syntax reduces the impedance mismatch between flie business requirements and 
technology implementation. The methodology described herein brings a unifonn 
structure to the thought process of business and technology people, fiom requirements 
analysis to design to implementation. The creation of business process applications as 
per this methodology forces the developer to focus on the business application logic 
rather than inftastructure code. Hie ftamework provides the reliability during business 
process execution by adhering to a set of design pattwns and exception handling. The 
.ftamework also provides the ability to create an inventory of reusable business 
activities which, as it evolves, significantly reduces the application development time. 

Ill] In view of the above described problems associated with the automation of business 
processes, at least one aspect of the preseait invention provides a system and method 
by which business process withm and between organizations and/or individuals can 
be automated using standards based, service oriented business process automation 
architecture based on XML and Web Services Standards including but not limited to 
SOAP, WSDL, WSIL, UDDI and BPEMWS. At least one aspect of the invention 
furthermore includes an execution ftamework for the business processes including but 
not limited to financial business processes applications involving simple and complex 
machine and human workflows, business rules evaluation, lifecycle management of 
business entities and integration witii existing applications. 

[121 Further, at least one aspect of the present invention provides a decomposition 
methodology for business process specifications into business flows, business rules 
and business states. The business flows, rules and states are defined in declarative 
languages including but not limited to standard or custom XML based languages. At 
least one aspect of the invention includes system and method for runtime execution of 
the business flows, rules and states described in declarative syntax on commercial 
and/or custom built flow, rules and state engines. At least one aspect of tiie invention 
includes the interaction, cooperation and coordination between the flow, rules and 
state engines; and the execution model for business processes withm the fitimework. 

[13] In yet another aspect of the invention, business process descriptions are classified 
according to a set of predefined taxonomy. This includes the mechanism to search 
business process definitions for a given name in a taxonomy category; and also given 
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a business process the categories and names it points to. At least one aspect of the 
invention furfhermore includes the management of the business processes executing 
in the framework comprising of registry, discovery, monitor. Service Level 
Agreement (SLA) managements and autonomic fulfillment of SLAs. 

[141 In another aspect, the present invention may provide a formal mechanism to define 
the semantics of business processes and their components. This may be done by 
annotating the business process specification with syntax for assertions including but 
not limited to pre-conditions and post-conditions, supported by rigid mathematical 
model, so that semantic correctness can be automatically verified at design time and 
run time. At least one aspect of the invention includes mechanism for automatic 
verification and guarantee of the semantic correctness of business process at design 
time and runtime. The system achieves correctness by semantic check and model 
checking of the declarative specification of the business processes. 

[15] Further, at least one aspect of the present invention is to provide a method for the 
constmction of a library of a semantically well-defined business activities or tasks. 
This makes it possible to automatic constmct new workflows including but not 
limited to exception flows within and across business processes based on a library of 
semantically well-defined components and business goals of the new workflows. At 
least one aspect of the present invention includes the algorithm for generation of such 
automatic workflows. 

[16] A yet further aspect of the invention is to provide a method for the loose coupling 
between business logic and presentation logic for business process applications. 

5 Brief Description of the Figures 

[17] Figure 1 provides a logical representation of flows, rules and states and mteractions 
between them in accordance with aspects of the present invention. 

[18] Figure 2 provides an example of a trading workflow in accordance with aspects of the 
present invention. 

[19] Figure 3 provides an example of portfolio retrieval in accordance with aspects of the 
present invention. 
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I20J Figure 4 provides a graphical representation of business process definition language 
in accordance with aspects of the present invention. 

121] Figure 5 provides an example of a task library forming part of the corporate action 
workflow in accordance with aspects of the present invention. 

[221 Figure 6 provide a graphical representation of a construct for a sequence in 
accordance with aspects of the present invention. 

[231 Figure 7 provides a graphical representation of a construct for a switch in accordance 
with aspects of the present invention. 



[241 



Figure 8 provides a graphical representation of a construct for a loop in accordance 
with aspects of the present invention. 



[25] Figure 9 provides a graphical representation of a business process management in a 
ubiquitous compute environment in accordance with aspects of the present invention. 

[26] Figure 10 provides an illustration of model checking in the business process execution 
fiamework in accordance witii aspects of the present invention. 

6 Detailed Desooptton 

[27] Aspects of the present invention relate to a system and method by which business 
process within and between organizations and/or individuals can be automated using 
standards-based, service-oriented business process automation architecture based on 
XML and Web Services Standards including, but not limited to, SOAP, WSDL 
WSIL. UDDI and BPEL4WS. At least one aspect of the invention furthermore 
includes an execution fiamework for the business processes including but not limited 
to financial business processes applications involving simple and complex machine 
and human workflows, business mles evaluation. lifecycle management of business 
entities and integration with existing applications. Aspects of the present invention 
further relate to a decomposition methodology for deconstructing business process 
specifications mto business flows, business mles and business states. The business 
flows, rules and states are defined in declarative languages and include die interaction, 
cooperation and coordination between the flow, rules and state engines, and the 
execution model for business processes witiiin the framework. 



6 



wo 2004/114061 PCT/US2004/018435 

[281 The various business flows, rules and states described herein may be resident on 
computer readable media including but not limited to removable media, fixed media, 
optical and magnetic storage, and the like. For instance, aspects of the invention may 
be resident in a host computer or computing network or on a client-side computer. 

[291 The following description is separated as foUows to assist the reader: 

6.1 Decomposition of a Business Process into Flows. Rules and States (FRS) 

6.2 Taxonomy of BPD and constituent Flows. Rules and States 

6.3 Declarative Specification of BPIs 

6.3.1 Flow Specifications 

6.3.2 Semantics of Actions 

6.3.3 Assertions at different points in the workflow 

6.4 BPI Execution Framework 

6.4. 1 Flow, Rule and State Engines 

6.4.2 Coordination between BPI Flows, Rules and States 

6.4.3 Management of BPIs 

6.5 Coirectuess of business process workflow 

6.5.1 Automatically annotate a workflow 

6.5.2 Automatically verify the correctness of a workflow 

6.6 Model Checking of Business Processes 

6.6. 1 Model Checking Approach 

6.6.2 Design Time Model Checkmg 

6.6.3 Runtime Monitoring 

6. 7 Automatic synthesis of Business workflows 

6.8 BPI Framework based AppUcations (possible examples but not limited to) 

6.8.1 Corporate Actions Management 

6.8.2 Order Management Systems Integration with Market Data. Portfolio 
and Comphance Applications *"»"uiiu 

6.8.3 Data Management System 
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I30J 



6.1 
(31J 



[32] 



The following sections relate to iUustrative schemas and example instances that may 
be used in accordance with aspects of the present invention. 

7 Schemas and Example Listances 
7.1 Schemal; BPDL Schema 

7.3 An instance ofthe Negotiation Data Model 

7.4 Example of high-level data model 



Decomposition of a Business Process into Hows, Rules and States (FRS) 
Business Process Management (BPM) is becoming more and more important in the 
business world. Companies are trying to automate their business processes so that 
they can lower cost and improve efficiency. In addition, they need the ability to 
quickly integrate new processes and adapt existing processes in order to fece the 
challenge of the fast-changing market 

A business process, in simple, is a collaborative execution of activities according to 
the specific business rules in order to achieve some business goals. An activity is a 
unit of work that is either automatically performed by a computer system, or manually 
by human beings. Activities, which are performed by computers or computer-human 
interactions, are considered here. The foUowing two examples show some typical 
business processes. 

[33] Example 1 (Figure 2): Tins example shows the negotiation process between two 
traders. A and B. The busmess goal of tins process is trying to reach agreement on a 
deal and then settle the deal through the confinnation process. The process starts 
when trader A contacts B and makes an offer (i.e., sell 1000 share of stock A at a 
certain price). If B accepts flie offer and makes a counter offer, A and B will start to 
negotiate mitil either one party quits with no deal or a mutual agreement is made. If 
agreement is reached, &e deal will be confirmed and settled. If the two traders belong 
to the same financial branch, the settlement can be done at once. Otherwise, each 
party has to settle ihe deal separately. 
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[34] Example 2 (Figure 3): In this example, the financial advisor wants to retrieve the 
portfolio information of a customer by his name. He first types in the name to seaich 
in the customer database. The summary information of each customer whose name 
matches the search criteria wiU be listed in a grid view. If there is only one customer 
listed, his portfolio information will be retrieved and presented automatically. 
Otiierwise, the advisor can choose one customer ftom the list and request his portfolio 
information being presented. 

[35] A Business Process Management System provides capabilities to design, deploy, and 
manage automated business processes. It provides tools for designing a business 
process using given activities as building blocks and foUowing the given business 
mles; It provides facilities to deploy and manage business processes in an 
organization; Furthermore, it provides a framework to control the execution of 
business processes and to coordinate the activities during an execution. 

[361 Business processes are becoming increasingly complex and there is a growing need 
for automated and streamlined business processes in a more distributed and 
heterogeneous environment. The activities involved in a business process are 
generally involving activities from different groups in an organization, or across 
different organizations. They are probably implemented with different computer 
languages, running on different platforms and using different protocols to interact 
with each other. The coordination among fliese activities and tracking them in a 
business process is a challenging problem. 

[37] Recently, the widespread adoption of web services has begun to fulfill the promise of 
a universally interoperable component model. Specifically, it makes reusability and 
language/platform independence possible in business process management. 
Components that are implemented in different languages and for different platforms 
can be packaged as web services to achiieve interoperability. The XML-based web 
services languages (e.g., SOAP, WSDL, UDDI) decouple unplementation from 
interface; as a result, an organization can, in theory, create entire solutions using best- 
of-breed web services as building blocks. Web services standards have matured to a 
"production-ready*' degree and contmue to evolve as acceptance increases. More and 
more, one finds web services employed in the enterprise to achieve enterprise 
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application integration (EAI) as well as business-to-business and business-to- 
consumer interactions (B2B/B2C). 



138] 



Yet m contrast to the technological maturity of web services, (he tools available for 
Busmess Process Management by web services orchestration remain relatively 
pnmitve. How does one express real world business processes as an aggregate of web 
services and message flows? In most cases. skiUed integrators create a "master 
application" which caUs the component web services in proper order, tracks key 
values used by them, aggregates the results, etc. This "code the business logic- 
approach can work, in the seme lhat it can successfully fulffli the business 
requirements of the moment, but it foils to leverage die benefits of the component 
model: When such a "point solution" is created rafter than a "productized solution" 
recumng patterns in business semantics camiot be easily reused the way recurring 
functionality can; they often need to be coded anew for the next solution to come 
along. Even worse, in an effort to gam reusabiUly. business semantic considerations 
can tend to get pushed into the web services Aemselves. corrupting the component 
model and reducing the web services' reuse potential. Without an adequate means of 
modeling higher level business abstractions, the IPR associated with the business 
process flows, data, and rules is lost. 

139] ' At least one aspect of the invention is a framework for business process management 
based on existing web services standards. The term Business Process Instance (BP]) is 
defined as an automated business process with arbitrary level of granularity, which 
comprises of business flows, rules and states. Multiple BPb can be organi«d in a 
hierarchy to represent the automation of a larger business process. A definition of a 
business process instance is called a BPD. At least one aspect of the invention 
includes the methodology for creating Business Process Definitions (BPD) in a non- 
traditional mamier and includes a framework to execution Business Process ^stances 
(BPI). At least one aspect of the invention includes an XML-based language, Busmess 
Process Definition Language (BPDL), to specify business processes declaratively. A 
BPI specification not only defines how the business process should be executed but 
also the exact "meaning" of executing the process, that is. what the proce^ is 
supposed to do. In another word, the semantics of a business process is formally 
defined in addition to its runtime behavior. The business process management 
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fiamewoik. refeired to as BPI ftamework. provides tool^, components and 
environment for business process definition, deployment, management and execution. 

140] A BPI uses activities and data entities as its building blocks. It assumes that aU the 
activities expose web service interfaces in WSDL. and therefore can be treated as web 
services. The data entities can be accessed as XML documents that are modeled by 
XML Schemas. BPDL describes a business process by decomposing it into three 
components: flows, rules and states. Hows define the control logic and data flow 
among the activities; rules define decision making poUcies and states define the 
legitimate behavior of business data entities in temis of state-transition models. 

[41] When creating a BPL the plain English description of a business process is 
decomposed into its constituent business flows, rules and states. The first level break- 
down is a combination of stractured English and diagrams in Unified Modeling 
Language (UML) or similar notations. The UML sequence diagrams and activity 
diagrams capture the execution order and logical dependency infoimation among 
activities in a business process, and therefore form the basis of the BPD Flow 
specification. The UML state diagrams capture the state transition of business entities, 
and form the basis of BPD State Model. The rules are generally associated with 
decision points in a flow or state transitions in a state diagram. The rules are separated 
firom the flow or state because, first, the rules might change but the general structure 
of the flow or state model keep the same. Second, the same rule might be used in 
different occasions. Third, it makes possible to externalize the business rules and 
empower the business user to change it. The flows, rules and states are then specified 
separately in a declarative form in BPDL. 

142] BPD Flow specification language is based on BPEL4WS. BPEL4WS is an XML- 
based standard to define web service orchestration protocols, or workflows. WSDL 
and the BPEL4WS language is extended so that formal semantics can be annotated on 
web service operations and BPEL4WS workflows. 



143] 



144] 



An XML based Business Rules Unguage (BRL) is used as the language-neutral 
description of varied types of business rules. 

An XML based State Machine Language, StateML, is used to specify the state 
transition models of different business entities. 
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[451 A BPD specification does not contain flie specification of flows, rules and statos 
directly. Instead, it refers to those definitions by adding a level of indirection. The 
following is a simplified example of a BPD specification on the trade negotiation 
process. 



<?xinl version="1.0" encodings "utf-1 6 "?> 
<BPD> 

<Name>NegotiationBPI</Name> 

<Description>Trade Negotiation Process</Description> 
<URI>http : //f auxuri . reuters . com/NegotiationBPI </URI> 
<Flows> 

<Flow> 

<Naine>Negotiation</Ncune> 
^, ■ <Description> negotiation process 

flow</Description> t^x^^^coo 

<URI>http: //f auxuri. reuters .com/NegotiateBPI/flow</URI> 
</Flow> 
</Flows> 
<RuleSets> 

<RuleSet Ma jorRevision="l" MinorRevision="0"> 

• <Name>Br anch< /Name> 
<Description>Decide if the two. traders are from the 
same branch</Description> 

<URI>http: / /f auxuri . reuters . com/negotiationBPI/rs/branch</URI> 
</RuleSet> 

<RuleSet MajorRevision="l" MinorRevision="0"> 
<Name>match</Name> 

^ <Description>Decide if one trader's request matches 

the interest of another </Description> 

<URI>http : //f auxuri . reuters . com/NegotiationBPl/rs/match</URl> 
</RuleSet> 
</RuleSets> 

<StateModels> 

<StateModel> ' 

<Name>NegotiationASM</Name> . 

<Description>state machine for trader negotiation 

data</Description> 

<URI>http : //f auxuri . reuters . com/NegotiationBPl/negotiation/sm</URI> 
</StateModel> 
</StateModel> 

</BPD> 
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6.2 Taxonomy of BPD and constituent Flows, Rules and States 

[46] The BPIs are analogous to components in a component oriented software 
development One of the drawbacks in the component oriented software development 
is that the enormous numbers of components overlap with each other and there is no 
central repository of components or information about components to avoid the same. 
In the Web Services paradigm this problem is solved by the notion of UDDI, which 
can be used as a repository for the meta-information pertaining to the web services. 
Since BPIs are exposed as Web Services the same technique is vaUd in case of BPIs. 
BPI definition by BPDL contains the classification information for the BPI and its 
constituent flows, rules and states. The taxonomy of BPI is captured as a node in the 
BPDL dociunent, as ^own in Figure 4, 



6.3 Declarative Specification of BPIs 

[471 With the business requirements properly decomposed into our three major component 
categories, the requirements can be expressed as a synthesized set in a BPD document 
through BPDL. the XML-based business process definition language. The W3C-style 
schema for BPDL is showed in schema 1, and is graphically represented in figure 4. 



[48] 



BPDL contains primary elements under the root element <BPD>: <Flows>, 
<RuleSets>, <StateModels>. <Entities>, <SubBPDs>, and 
<Views> . We have aheady discussed the place of flows, rules, and state models 
within a BPD. Views provide reusable GUI capabilities in the same fashion that the 
other elements provide reusable back-end capabilities. Entities point to named 
business entities based on XML schemas related to the business process. And Sub- 
BPIs allow for existing BPIs to be reused as it is in much the same way that individual 
components are reused. Each of these primary elements contains one or more sub- 
elements designating a single instance of the parent collection through the use of a 
common set of sub-elements; this set, whose schema is captured in schema 1, 
provides the information necessary for the runtime and design time coordination of 
the primary eleme^ts. These common elements are also applied to tiie BPD element 
itself, so other BPDs may reference it in a hierarchical fashion. 
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149] A BPD element also contains an element holding taxonomy infonnation to faciUtate 
searching. The proper taxonomic classification of a BPD is absolutely necessary to 
obtain the value of business process reuse. The taxonomic elements contain data to 
identify the function and purpose of the DPI with respect to estabKshed terminological 
dictionaries. When a BPD is stored with taxonomical tags in a BPD repository, a BPI 
design tool can parse this information and make it available to developers seeking 
business processes of a certain type. 

[SO] Within the set of common sub-elements, one is for use exclusively by a BPI design 
tool, and the other two are primarily for use by the BPI runtime engine. In the former 
category is <Description:>, which provides a longhand summary of the purpose 
of the element and any features of note. This summary would be displayed to the 
developer when browsing components in a BPI component repository. The other two 
elements provide the means for component resolution and invocation. <URI> 
designates a unique resource identifier for the specific component in order that a BPI 
engme could locate and mvoke it. This is m keeping with the overall vision fliat 
BPDL does not provide details about flie components themselves, only a way of tying 
them together. If <URI> designates the pieces that are tied, then <Name> elements 
are the strings that do the tying. <Name> gives a BPI name to the component, by 
which other BPI-ready components can refer to it. These names need to be uniquely 
resolvable both within a BPD, and in the larger context of any assemblage of 
hierarchical BPDs. 

151] The BPI fiamework enables the coordmated integration of flows, rules, and state 
through the employment of two fundamental concepts. The first is reciprocal abstract 
invocation. This refers to the ability of flows, rules, and state engines to invoke each 
other through named references passed to the BPI fiamework. It is certainly possible 
for flows, rules, and/or state to be wired together without taking advantage of BPI 
technology: for example, a flow could call a rule to determine which flow path to 
take; a rule could request a state transition if the rule evaluates as false; and a state 
transition can trigger a flow execution to provide complex logging of the transition. 
But the drawback of this direct-reference strategy is that the coordination is static, 
with the specific references built into the flows, rules, and state machines. BPIs 
abstract this relationship, and the BPI-ready flows, rules, and state machines reference 
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each other by BPI name, not address. If we look at a BPPL document describing 
given BPI, we will see entries like the following: 

<RuleSet> 

<Name>Ma j orClientRule</Name> 

^np?^^^?^^?'^^" ^^^^ ^ ""^^^^ client?</Descript±on> 

</RuleSe?> ' ^^^^'^''"''^ " ^^'^terg . com/crm/client/categorize . asmx</DRI> 



[52] An example of direct invocation will be. if a flow need to invoke the raleset above, 
the flow would have to include an instruction to call 
"http://fauxuri.reuters.com/cmi/client/categorize.asmx". Later, when another more 
sophisticated version of the ruleset became available at 
"http://fauxuri.reuters.com/crm/clien1/new-categorize.asmx", the flow itself would 
have to be changed to utilize it. However, in the BPI framework, this is avoided by 
never calling the mieset directly, but by instead asking the BPI engine to invoke 
ruleset "MajoiClientRule". To utilize the new mieset, no change to the flow is 
needed, only a change to the BPDL document. 

[531 The second concept is mutual data accessibility between flows, rules and state 
machines. All should be able to reference, evaluate, and modify the same copy of the 
business data while they execute. The importance of this should be obvious: if during 
the course of a business process, a flow engine, for example, modifies a particular 
piece of data, a subsequent call to, say, a rule engine will need to be aware of that 
change to evaluate the rule correctly. To help manage data, BPI uses the constmct 
"entity" to separate the data from the business process. Rather than a requesting data 
from a particular location as a primitive flow might, the BPI-ready flow requests data 
from a BPDL-described entity. The BPI framework leverages state machine's 
capabiHties to manage the lifecycle of data; thus, an entity wiU be associated with a 
state machine to provide for its instantiation, state progression, and destruction. 

[54] With reciprocal abstract invocation and mutual data access providing usable but 
flexible connections between a BPDL-described set of flows, rules, and states, the 
BPDL can fulfill its stated purpose of embodying a logical set of business 
requirements in its fulhiess. Additionally, BPDLs can be hierarchical, referencing 
each other in BPDL by name in the same fashion that a named flow can caU a named 
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[55] 



156] 



nUe. H^us. individual BPIs can be stacked and arranged together to form higher order 
BPIs automating larger business processes. 

Named references not only allow for runtime resolution of processes and entities, but 
for design-time dependency analysis as weU. As components get added to a BPD a 
BPI Designer can indicate what other named flows, rules, state machines, and entities 
the component refers to. and direct you to associate other components with the BPI 
untd no hanging references remain. With every internal reference to named 
components verified against BPI names in the BPDL document, the designer can be 
assured of runtime consistency. 

The real elegance of the BPI framework is its use of these features to capture the 
essence of busmess requirements in the manner in which they were mtended. without 
burymg them into the constraints of a single implementation technology. A process 
best exprt^ssed as a flow can be, while another perhaps best embodied as a rule may 
be so without sacrificing the capabilities of each to work together. Furthermore, it 
permrts subsequent changes to the choices of components used to fhlfill those 
requuements to be made at minimum cost. By increasing the impedance between 
business requirements and technology implementaiton and decreasing the cost of 
subsequent evolution of those requirements, the BPI fiamework makes possible a new 
level of maturity in building business solutions 



6.3.1 Flow Specifications 

[57J A business process involves several actors, either human beings or computer services 
performing activities collaboratively to achieve some business goals. n.e control' 
logrc and the data flow among the activities are generally coordinated by a controller 
The control and data flow logics of a business process can be shown graphically as in 
Example 1 (Figure 2). and Example 2 (Figure 3). 

1581 Tire control flow and data flow of the business processes can be defined in a 
workflow specification language. If we model each task as a web service that can be 
descnbed by WSDL. then a web service orchestration language, such as BPEMWS 
can be used to define the workflow of a business process. 
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[591 We assume the following constructs fix)m BPEWWS are used to construct a 
workflow. Note that though BPEL4WS is used as the basis of BPD flow specification, 
other workflow or web service based specifications can also be used if they are based 
on constructs of similar semantics. 



Invoke 

parameters 



[60] An operation invokes a web service or another workflow by assigning values to the 
narameteTs 



<invoke operation="negotiate . Contact"> 

<arguinents> 

<arguinent inciexs="l"> 

<name> . , . </haine> 

<value> . : . </value> 

</argument> 

Orgiiment index="2"> 

<nanie> . . . <7naiae> 

<value> •. , . </value> 

</argument> 

</arg\aments> 
</invoke> 

[61] The invocation of a task is different fi-om the invocation of a web-service as in 
BPEL4WS. A web-service end point in WSDL is based on message passing and does 
not have semantics defined. A task has semantics and a set of parameters. 

Assignment 

[62] Assign value to a location. 



<assig'n> ^ 

<from> . . . </f rom> 
<to> . , . </to> 

</assign> 



Signaling faults 

<throw> name </throw> 



Termination 

[63] Terminate the execution. 
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<terminate/> 

Waiting 

[64] Wait a certain amoiuit of time. 
<wait time=""/> 

Doing nothing 

[65] An empty operation does nothing. 
<empty/> 



Structured Activities 

[66] Simple activities can be put together to build complex activities. The following 
constructors can be used to construct complex activities. Before or after each activity 
or activity block, an assertion can be added to assure flie workflow state satisfies some 
correctness criteria: 

Sequential constructor 

[67] A sequential constructor executes several activity blocks sequentially. 

<sequential> 

<l- activity block 1 — > 
<!- activity block 2 — > 

</sequential> 
Concurrent constructor 

[68] A concurrent constructor executes several activity blocks concurrently. The 
constructor terminates when all concurrent activities terminate. The flow element is 
used to specify a concurrent constructor. Links define the dependencies among the 
activity blocks. 
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<flow> 

activity blocks 
<links>? 

<link naiae«"ncname">+ 

</links> 

</flow> 



Branching constructor 

[69] A branching constructor executes one of several activity blocks. When lhat block 
terminates the constructor terminates. A condition is specified for each block as an 
assertion. Only when the condition evaluates to true can the block be started. If more 
than one condition evaluates to true, more than one block can be chosen to start. In 
this case a block is chosen non-deterministically from among those with true 
conditions. 



<swltch> 

<case> 

<condition> 

<f ormula> . . , 

</condition> 

<activity> . . 

</case> 

<case> 
. <condition> 

<formula> , . . 

</condition> 

<activity> . . 

</case> 

<otherwise> 

activity 

</otherwise> 
. </switch> 



</ f ormula> 
► </activity> 



</formula> 
. </actlvity> 



While constructor 

[70] A while constmctor executes the activity block inside the loop while the guarding 
condition is true. It repeats executing the activity block until the condition evaluates to 
false. 



<while> 
<condition> 

<forniula> . . . </fGrinula> 
</condition> 

<activlty> ... </activity> 
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</while> 
Race constructor 

[71] A race constructor starts several tasks concurrently, but only the one that finishes first 
takes effect. Other activity blocks will be aborted. 

<race> 

activity blocks 

</race> 

Exception handling constructor 

[72] Exception conditions can be specified as a global condition and a handler as a sub- 
flow to handle the condition. When the condition becomes true, the current executing 
sub-flow will be stopped and the handler will be executed. The handler can then 
throw new exceptions to the outer block. Unhandled exceptions will be thrown out the 
outer block automatically. This provides a structural way to handle failures or 
exceptional events that could be produced firom any tasks in a sub-flow, as shown the 
above example. To specify exception situation in a workflow specification, we use the 
following notation: 

<catch> 
<condition> 

</conclition> 
<activity> 

. </activity> 
</catch> 

Event 

[73] An event is generated either because a timer times out or an external message is 
received by the workflow controller. 

<event> 
<name> 
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</naine> 
<type> 



</type> 
</event> 



Pick 

[741 Choose one path to execute depending on which event happens first. 



<pick> 
<OnEvent> 

<name> . . . </name> 
<activity> 

</activity> 
</OnEnvent> 
</pick> 



6.3 .2 Semantics of Actions 

175] The following sections describe the Semantics of Actions in the Business Process 
Framework. 



6,3.2. 1 Introduction to SemanticL 

[76] A mathematical model is developed to fonnally specify the semantics of a workflow. 
A declarative language, SemanticL, based on the model is designed to fonnally 
specify the semantics of BPI flows. 

I77J In a BPD specification of a business process, the flow is specified declaiatively using 
an XML-based workflow language. Many workflow specification languages have 
already been proposed, such as BPEL4WS, WSCL, etc. BPEL4WS is chosen to be 
the flow description language in BPD. Those languages are adequate to describe the 
control flow logic of a business process. However, none have provided a way to 
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describe their semantics, or exact •'meaning". Therefore, correctness can not be 
guaranteed by the system automatically, but relies on manual testing. 

SemanticL is not meant to be yet another workflow specification language, but a 
language used to amiotate workflow specifications to formaUy define the semantics of 
the workflows and their components. SemanticL is based on a rigid malhematical 
model, so that semantic correctness can be automatically verified at design time and 
run time. In addition, new workflows can be automatically coistmcted based on a 
library of semantically well-defined components and business goals of the new 
workflows. 



6.3.2.2 Formal Model for Describing Workflow Semantics 

179] A formal workflow model is described. The semantics of a workflow can be precisely 
defined based on the model. In this model, a workflow specification is abstracted at a 
high level to facilitate logic representation and reasomng. The abstracted workflow 
specification is called A-BPD. An A-BPD is defined as a 4-tupIe- 
<workflow database, task library, workflow> . The definition of each term and their 
relationship to BPD flow is described later. 

Definitions 

[80] domain, variable. ' and constant: A domain is a finite set of objects of the same type. 
For example. D = a2,...,100} represents a domain of mtegers from 1 to 100. Atakes 
its value firom a particular domain. For example. x^D defines a variable x on 
domain D. Constants are interesting values on a domain. For example, 10 is a 
constant in Z? and TRUE, FALSE are constants in the domain Boolean. 

[811 predicate: Predicates asserts some properties of an object or relations of objects. A 
predicate is in the formP(x.,x„...,x,). The number of parameters and the ^e of 
each parameter is predefined for each predicate. A predicate fliat does not take any 
parameters can be represented as a symbol that evaluated to ei&er true or false. If P 
is a predicate. 
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182] Predicates are used to characterize the current state of the workflow. For example. 
Contacted is a predicate in the negotiation workflow. It evaluates to true if trader A 
contacts B successfully, false otherwise. 

literal: A Uteral is either a predicate or the negation of a predicate. 

literal := {predicate | -.predicate} 



worl^ow database: The set of predicates that make up the workflow forms the 
workflow database. Workflow database is directly related to the abstract data model 
in BPDL. A leaf element in the abstract data model corresponds to a predicate in the 
workflow database. The predicates are globaUy visftle to aU the tasks. For example 
the following is the workflow database for the negotiation example: 

^Contacted, Accepted, NewBid_A, NewBid_B, 
Interrupt_A, Iaterrupt_B, Agreed_A, Agreed_B,' 
Confirmed_A, Confirmed_B, Settled_A, Settled_B, 
Nodeal, SameBranch;. 



[84] formula: A formula is a well-formed first order logic formula based on a given 
workflow database. To be specific: 

1 . A predicate is a formula. 

2. If P.g are formulas, thenP v 2 , P a g are formulas. 

3. If P is a formula, then -tP is a formula. 

4. If /> is a formula and * is a variable, then V(x)P and 3(x)P are 
formulas. 

[85] task: Tasks are building blocks of a workflow. A simple task is a task that performs 
an atomic action that satisfies the ACID properly. A complex task is composed of 
other tasks as a sub-workflow, and therefore is not atomic. When two complex tasks 
are running concurrently, their activities may interleave in an arbitrary way. We will 
initially assume no interference and we will return to this issue later. 

[86] A simple task T is described hy {P}T{Q} . P is the precondition of T , T execute 
correctly if and only if P is true when it started. For simpUcity. we only consider P 
in the form of a conjunct of literals: 
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P:= A(/itera/). 

187] In Ihe case that T can be started in several different states: 
[88] We can view T as a set of tasks: 

[89] Q is the postcondition of T . Task T can have several possible termination states, 
and one is non-detenninistically chosen when it finishes. Q is of the form 
(5.AQ)v(5,Aa),...,v(5„Ae„). where Q, is a conjunct of Kterals. and 
S„S^,...,S„ are status variables observable by the workflow controller. One and only 
one of S,,S^,...,S„ is true when T finishes, and is chosen non-deterministically by 
the task. For simplicity, we represent (5. a^,) v(5, Ae,).....v(5„ aGJ as 

[90] For example, a task Negotiate_A is described as: 

{newbid_Bvinterrupt_A}Afe5o«ate_^{(newbid_AA^newbid_B),agree^^^^ 
[91] The task definition follows the firame semantics. Frame semantics means that 
executing a task only affects the predicates mentioned in the postcondition. Formally, 
frame semantics can be defined by the Result function: 

[92] I- is the workflow state when T starts, and i" => P is true, then when T terminates 
Result(/",e,) is true, whei© 

1931 Itesul<(P',e,),R«,ult(/>',a) Resultcne.) deflHM all the possible workflow 

States when T finishes. 
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[94] Or we can reason backwards ftom the state where T finishes. Suppose when T 
finishes, is trae, whereg => Q , 

Residue(e',eO = A(e'.GO, where G'-G^' is the set difference of the sets of literals 
in 2' and^f. 

[95] /'AResidueOS',a)AResidue(Q',ej,...,AResidue(e',a) should be satisfied when 
T starts. 

[961 A BPDL specification of a task can be translated into an A-BPD specification easily 
according to the relationship between abstract data model and workflow database. 

Workflow specification: 

[97] A workflow is specified in the following form: 

{p,,p„P3,...p„}fFF{e„e3,e3,...Qj 

Where are conjunctions of literals and mutually exclusive. epQ2»-.2„ are 

in the form 

[('S„Ae„)v(5i,Aa3)v..o],[(5,,Aai)v(5,2Aa,)v..^ 

Which means one of WF's precondition should be true when it starts and if /J is true 
then gj is the postcondition and so on. 

[98] A task is a special case of a workflow specification in that it has only one 
precondition and postcondition pair. 

[99] Workflows are constructed firom tasks using workflow constructors. If the complete 
constmction is given, the firame semantics of the workflow can be derived and the 
workflow can be treated as a task. 

Semantics of Workflow Constructors 

[100] We allow the following constructors in a workflow specification. 
Task 

[101] If the workflow is in state P and a task is executed, then we have the following 
inference rule: 
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{P}7;{Result(/»,fi,)} 



When reasoning ftom backward. 



{i? A Residue(e,a)}7; {Q} 



Sequential 

[102J A sequential constructor specifies two tasks execute sequentially: SEQ[7;, means 
r, is executed and thenT,. We have the foUowing infereftce rules for sequential 

constructors: 

{P }SEQ[r„ {Result(Result(P, g,), g,)} 



{P, A Residue(Residue(2,e,),gj}SEQ[r,.r2]{e} 



AND 



1103] The constructor AND[r„rj specifies the two tasks execute concurrently: We have 
the following inference rules for and constructors provided there is no interference: 

{Pi}TAQ,}AP>m{Q^,P^P„P^P^ 
{P}AND[j;,rj]{Result(/>,fi, aQ^)} 



{P,}T,{Q,UP,m{Q,},Q, aQ, =» O 
{/? A Residue(e,e, Ae2)}AND[2;,r3]{0} 



OR 
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[104J Tho constructor OR[T„T„C] specifies that if C is true, then T. is executed 
otherwise is executed. We have the foUowing inference rules; 

{PmQ,}AP:,)TAQ,UP^C) o i>,(P A -.C) => R 
{P}OR[7;,2'2,C]{Rfisult(/>AC,0,)vRfisult(i>A-,C,e,)} 



{(CAi> AResidue(e,e,))v(-,CAPj AResidue(e,a))}OR[7;,r2,C]{(g} 



RACE 



U05J A race constructor RACE[2;.rj specifies two tasks running concurrently. However, 
the first to finish wiU commit and the other one wiU be aborted. 

{P>RACE[r„r,] {(S A Result(/>,a)) v (-.S a ResultCP.gj))} 



{Pi}Tr{Q.}AP.m{Q,},Q, ^Q^^O 

{P, A (Residue(e,e,) v Residue(e,e,))}RACE[r,.r2]{G} 



LOOP 



[106] A loop constructor LOOP[7;.C] specifies the task T] will be executed repeatedly 
untU C becomes true, where C is a well-formed formula. The loop concemed here is 
a repeat loop, in the sense that flie loop body T, is executed at least once. A while loop 
can be constructed easily using a repeat loop and an OR constructer. 



Due to the fact that the loop condition C and the task T, are both specified as logical 
formulas, Ihe loop constructor is less powerful than the loop in a general 
programming language. The reason is because no matter how many times the loop 
body is executed, when we reach the starting point of the loop constructor, the 
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workflow state wiU always be the same. The loop invariant is simply/* aC. The 
semantics of the loop constructor is retrying T^ until it gives us the desired output, 
assuming J, has several non-deterministic outputs. 

{PxmQ^),P => i',.Result(f ,Q A C) => /> 
{P}LOOP[r„C]{Result(i',g, A-,C)> 



{/>. }7; {js A V (-.^ A g)}. => .Q, => c? 

{i> A Residue(fi,ej)}LOOP[r,]{e} 

[108] A necessary condition for a weU formed loop is that the postcondition of the loop 
does not have a contradiction: 

-iCAgi ^ False 

[109] This happens to be a necessary condition for the termination of the loop. If we assume 
of r, 's output satisfies the faimess properly, then the condition is also sufficient. 

Event and Pick 

[1101 An event is a special kind of task. An event is a message sent to the workflow 
controller from outside. The workflow controller has no control of when an event 
happens. However, the workflow controller wfll recognize the events that are 
registered with it and response to it accordingly, such as starting a new workflow 
instance or continue a waiting workflow that is waiting for the event to happen. An 
event can be specified as a task with precondition as true. 

{TRUE}E{Q}. 

[Ill] Event caimot be used in a workflow specification. Instead, a constructor called Pick is 
used to specify the workflow is waiting for some event to happen. A pick can have 
one or several Receive clauses. Depending on which event comes first, one block will 
be picked up and executed. 

[112] The semantics of a Pick constmctor is similar to that of a Race, assuming tiiat exactly 
one of the waiting events will eventually happen. 
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{/>}PICK[RECEWKL^,7;].RECEIVE[^, 2,J JU. ;Kesult(Ke^^^^^^ 




6.3.2.3 Semantics of Actions 
Data Model: 

1113] The data model defines the data schema underlying a business application or a set of 
related business applications. In addition, describes the absliact data model on which 
the semantics of the tasks and workflows are defined. 

1114] The data model is defined as semi-structured data types based on XML-Schema 
There are many industry standards, such as FpML and NewsML. which are based on 
XML-Schema. They form the basis for many applications. 

1115] BPDL provides notations of both a concrete data model and an abstract data model 
The concrete data model is the actual data model that a workflow controller uses at 
run time, whereas the abstract data model specifies only some high-level information 
that IS required for semantic specification, verification and simulation purpose. 

Concrete Data Model 

I116J The concrete data model defines the data schema that is required for workflow 
execution. 

[117] For example, the data model of a negotiation process can be defined as shown in 7.2. 
m the form of XML-Schema. This can be considered as an extended version of the 
FPML standard. An instance of the negotiation data model is iUustrated in 7.3. ' 



Abstract Data Model 



29 



wo 2004/114061 



PCT/US2004/01843S 



[118J The abstract data model is an abstraction layer on top of the concrete data modei. It 
defines the properties fliat would be used to specify the pre and post conditions of 
tasks and workflows. For example, a predicate called Confirmed is defined for a 
trader. Confirmed is true if the trader's deal is aheady confirmed, false otherwise. 

<property 

expression=" (negotiation/CurrentBid/bidder/conf irmed = "™^=''°°"f 

(negotiation/CurrentBid/Zlstener/conflrmed = yes)"/> 

U191 The properties are defined as XPATH expressions on the concrete data model that 
evaluate to Boolean or integer values. For example, confirtned is defined as at least 
one trader reached the confirmed state. An example is shown in 7.4. 

Task and task library 

[1201 Tasks are building blocks of workflow process. Tasks are generally specified as a 
w^b-service interfece with WSDL. Semantics of a task is specified in the form of pre 
and postconditions. 

fl21J A task has a set of preconditions. The preconditions have to be satisfied when the task 
starts executing. The pre and post conditions are Boolean expressions on the abstract 
data model. The execution body of a task can be either an appUcation outside the 
workflow engine (simple task) or a sub-workflow (complex task). 

Requires 

(1221 Requires specifies the pre-conditions of a task. It can have one or several require 
elements. Each require element has a set of formula elements. The formula element is 
a Boolean XPath expression on ihe abstract data model. A reqmre element is satisfied 
if and only if all the contained formula elements are tme. At least one of the require 
element should be satisfied before starting the execution of the task. 

<requires> 

<requlre> 

<formula> negotiation/SingleConfim 

</formula> 

</require> 

</requires> 
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Guarantees 

[123] The Guarantees element specifies the post-conditions of the task. Similar to the 
require element, each guarantee also has a set of fomiula elements. When tiie task 
finishes successfully, one and only one of the guarantee elements is chosen as the 
output, and the workflow data is guaranteed to be updated accordingly so that the 
XPath formula evaluates to true. In addition, only fields exphcitly specified in 
guarantee are affected by the task and other fields in the abstract data model are not 
changed. 

<guarantees> 
<guarantee> 

<formula> negotiation/DoubleConf irm » true 
</formula> 
</guarantee> 
<guarantees> 

Exceptions 

[124] Exceptions specify the exceptional post-conditions of the task as an XPath expressioa 
It is similar to the guarantees specification. The only difiference is that it defines the 
possible output when a task fails or exits abnormally. 

<exceptions> 
<exception> 

<formula> negotiation/ timeout </formula> 
< /except ion> 
<exceptions> 

6.3 .2.4 Semantics of Workflow 
Requires and guarantees 

[125J In a manner similar to a task specification, a workflow specification can have 
requires, guarantees and exceptions, which are the same as in a task specification. 

Constructors 
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[126] Constructors follow the syntax in BPEL4WS in general, and we provide a way to 
annotate them witit assertions. 

<assert> 

<formula> XPath expression on the abstract data model </formula> 
</assert> 

6.3.3 Assertions at different points in flie workflow 



6.4 BPI Execution Framework 

[127] The following sections describe the BPI execution ftamework. 
6.4. 1 Flow, Rule and State Engines 

[1281 BPI Execution Framework has three core components: flow engine, mle engine and 
state engme. The three engines interact with each other and invoke existing domain 
services during an execution of a business process. 

[129] Domain services provide domain specific functionalities as web services. For 
example, Customer Relation Management Services provides functions related to 
managing customer relations, such as retrieving customer information, searching 
customer directory, etc. Domain services provide building blocks that can be 
integrated into new applications. 

[130] Flow engme orchestrates web services according to a given workflow specification in 
the form of a BPEL4WS program. When a workflow is deployed at a flow engine, 
unique entry point(s) of that flow is created as web services. A new instance of flow 
execution will be created and started when a message is received in the corresponding 
entry point During the execution, the flow may invoke domain services to perform 
domain specific functions, invoke rule engine to evaluate rules and invoke state 
engine to request state query or transition. Since flows are deployed as web services, 
they can be invoked by other flows. 
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tl31I State engto manages budneas o«=ct life cycte based on aute machine model,. State 
engme controls the state data and nser^efined data of a busineas object instance a, 
nm tnne. Tbos. data camK>, be updated outside the state engine. State machine 
models define to legitimate states, tasitions between states, and operations 
.ssoc.a.«l with transiaons of a business obj«=t A, run time, new instances of a state 
m«,hiae wiU be created according to the model when a create request is received 
Wh^ requests for transition, on state m«,hine instances are ^ceivcd. the state engine 
™u first to requested hansitions are enabled. If enabled, to state data will be 
updated accordingly and to associated operations, such as user data update or web 
service i„«>ca«on. wni be performed. A state engine has a single web service 
interfece for all the state machine models. 

I132J Rules engine evaluates complex business rules and can possibly perform some actions 
depending on what rules are evaluated to true. Business rules are specified in a 
declarative language, such as RuleML. At run time, a rules engine will evaluate a set 

of rules on a set of data at request Like the ctate i 

rwjucsi. i.uce me state engme, rules engme exports only a 

smgle web service interfece for all rule evaluation requests 



6.4.2 Coordination between BPI Rows. Rules and States 

U33J A business process execution requires that flows, rules and state coordinate and 
interact with each other. However, engines of flows, rules and states can execute 
independently. They are loosely coupled together through web service interfeces 
Figure 1 shows the logical relationship among their mterfaces. Hard lines with arrows 
in the graph show the invocation relationship among different interfaces, and dashed 
lines show data flow relationship. 

[134] Each flow has its own unique web service interface. For example. Fl has interface 
IFlowl; F2 has interface IFlow2; and F3 has interface lFlow3. The rules engine has a 
smgle mterface. Requests for evaluating Rl. R2, and R3 aU go through the same 
interface. State engine also has only a single interface. Query or updates on all state 
instances are requested through that interface. 

[135J During execution of a flow, rules engine can be invoked to do rule evaluations and 
state engme can be invoked to do state transition and data update. Rules engine can 
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Start a flow or invoke the state engine as triggered by fee results of some rule 
evaluations. State engine can call the rules engine or start a flow if a transition is 
successfidly performed. The reciprocal invocability of ttie three is shown in Figure 1 
by tiie arrows LI, L2 and L3. 

[136] Business object data is guarded by the state machine and can only be written or 
updated through the state machine. This guarantees the data will stay in legal states 
and can only be changed via legal transitions. Flows and mles can opemte on 
unguarded data and can perform read-only operations on guarded data. Optionally, to 
improve performance, guarded data can be repUcated into a read-only data store. 

6.4.3 Management of BPIs 

1137J As BPIs are deployed in ubiquitous compute enviromnent. the management of BPIs 
becomes vital. The BPI management consists of registry, discovery, monitor. Service 
Level Agreement (SLA) managements and autonomic fidfi'lhnent of SLAs 
(Management BPIs and End Point Resolution) when violations occur. Tte following 
sections will discuss each of these aspects in detail. Figure 9 provides the 
diagrammatic representation of BPI management A point to note here is that the 
management of BPI is a business process akd that is automated by using BPIs, which 
are referred as management BPIs. 



6.4.3.1 BPI Registry: 

[138] The BPI registry consists of three parts. One, the end points of the BPIs (either logical 
or physical) and the second, the SLAs agreements and the third the Taxonomies. 
Either a central or federated registry is required to store this information. TTie 
semantics of the BPI registry are: Each of the BPIs and its constituent (flows, mles 
and states) are mapped in to abstract interfeces. Each of the abstract interfaces has one 
or more instances of run time endpoints. Each of the runtime instances wifl have 
instance data where flie various SLAs. configumtion and taxonomies are defined. Any 
persistence store can be used as BPI registry. The following paragraph describes how 
UDDI can be used as BPI Registry: 
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6.4.3 .2 BPI Registry using UDDI: 

• Each of the BPIs and its constituents are mapped into UDDI tModels. 

• The description of BPIs and its constituents is mapped to UDDI overview document 

• The SLA agreements, configuration and Taxonomies are mapped to UDDI instance 
data 

• The BPI Taxonomies are mapped to UDDI Taxonomies 

6.4.3.3 BPI Discovery 

[139] After the BPIs are deployed based on the configuration stored in the registry 
(described above), there is always a risk of deployment and the registry being out of 
sync because of their discoimected nature. This problem is solved by monitoring tiie 
traffic to the BPI endpoints and provide feedback to the BPI administrator, an ability 
to either sync up the registry or identify rouge BPIs running in the environment. 



6.4.3.4 BPI Monitor 

[140] Since BPI end points are SOAP end points, the messages are monitored for various 
characteristics of SLAs in either real time or near real time (for performance reasons). 
When violations occur, the monitoring agents notify "Management BPIs" to take 
appropriate actions. 



6.4.3.5 Management BPIs 

[1411 Management BPIs are special BPIs that receive the SLA violations (described above) 
and make decisions on fulfilling the SLAs. Taking a sunplistic example, when a 
particular flow service reached 80% of its capacity the, BPI Monitor notifies the 
Management BPI and the Management BPI adjuste configuration in flie BPI registry 
such fliat subsequent calls to the flow service is routed using End Point Resolution 
service to a different end point till flie first one can sustain tiie SLA. The management 
BPIs also provide "SLA tolerance and sustain managemenf ' to avoid feedback based 
oscillations. 
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6 .4 .3 . 6 End Point Resolution service 

[142] At BPI runtime, every BPI constituent when it needs an endpoint, queries the BPI 
registry based on the interface, SLAs and classifications and gets the end point that 
needs to be invoked. This provides dynamic discovery of endpoints and provides the 
ability to reroute the BPI calls based on the configuration adjustment carried out by 
the Management BPIs in order to fulfill SLAs. 

6 . 5 Correctness of business process workflow 

[1431 A workflow is correct according to the given requirement if the postcondition of the 
workflow requirement is asserted to be true by the workflow specification, suppose 
the precondition of the workflow is true when it starts. 

[144] Based on the semantics of tasks and the inference rules of workflow constructors, 
correctness of a workflow can be verified at compile time. 

6.5.1 Automatically annotate a workflow 

[145] Given a workflow precondition, assuming each task's pre and postconditions are 
given, a v/orkflow can be automatically annotated at every execution point of what 
should be true at that point. 

[146] The algoritimi AutoAimotate takes two parameters: A workflow W and a precondition 
P of the workflow, and output W*, an annotated version of W. 

Algorithm: AutoAnnotate(W, P) : W 

1. IF W is a task {PJTi {Qi}, apply the TASK rule: 

{P}r,{Result(P,0,)} 
RETURN {P}Ti{Result(P, Qi)}. 

2. IF W is composed with a constmctor W = CON(Ti, T2, ...), apply the corresponding 
constructor rule and recursively annotate Ti, T2, . . . 
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6.5,2 Automatically verify the correctness of a workflow 

[147] First we annotate a workflow. Then if an assertion does not imply the precondition of 
the next task, there is an error at that point The workflow is wrong because the next 
task's precondition is not satisfied and therefore cannot be started at that point 

[148] If the last assertion does not imply the postcondition of the workflow, the workflow is 
wrong because the workflow does not satisfy the predefined postcondition. 

6.6 Model Checking of Business Processes 

[149] Model checldng formally verify whether a system implementation satisfies its 
requirement specification. Industry and academia has been developing model 
checking methodologies and automatic verification tools for various software and 
hardware systems. However, very few are applied in business processes and 
applications because of their complexity and lack of formal specification. 

[ISO] BPI provides a way to abstract a business process and describe it formally as flows, 
rules, and states. The correctness of flow and state specification can be verified using 
model checking technique. Based on this, BPI framework offers an approach to model 
checking the correctness of a business process. The BPI model checking tool takes the 
flow and state specification as the system implementation, and checks them against a 
set of system requirement specifications derived firom the original business 
requirement automatically. It can be used to enforce correctness both at design time 
and at run time. 

[ISl] Model checking is different firom flie semantic-based verification in the following 
aspects: First, model checking is based on observational trace semantics, that is, the 
observable sequence of states in a possible process execution; whereas semantic- 
based verification is based on formal semantics of activities and flows. Second, the 
former can be used to verify temporal properties, such as A must happen before B, A 
eventually will happen, there is no deadlock, etc; whereas the latter cannot be used to 
verify such properties. Third, the former needs to explore the whole state space of a 
system execution; whereas the latter is based on form deduction on the system 
specification. 
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U52, BPI model checking tool helps us to achieve the following objectives: check design 
tune correctness, cnfo^e nintime correctness, and ensure security. Security is 
especiaUy important in a distributed environment From the model checking 
perspectrve. security problem is a subset of reliability problem, which can be treated 
by language-based techniques. Our model checking tool ensures security policies for 
infomiation flow and therefore guarantees confidentiaUty. 



6.6. 1 Model Checking Approach 

1153) Cto ™dd 0^1^ ^ ^ ^^^^ 

rf "° ^ '^'"^ ab^rac. ««e machtae mod,l. and «,« 

checked H» methodology is simmiaifaed in Figure 10, 



6 6.2 Design Time Model Checking 

im Ihe fetstep is to fonnally defce fte systen, imp,eme„,a«on and ihe re,ni«n,en, 
3pcc^oa«on. bo* of which ^ derived from fte business re,ui«me„t From fte 
rciu^ement of a Business process, BPI allows us to specify the flows in BPEMWS 
«.d tte state models in tenns of StateML. which is based on a hie«n=hical state 
™ model. TT„,se procedures are indicated in Figure ,0 as dashed arrows In 
«14t,on. business re,™,emeo.s an, abst^ctad and fonnalized as temporal predicates 
m the form of temporal logic. The set of temporal predicates specifies the tempore 
constraints that the sys,«n has to observe. This procedure is indic,«l by arrow g in 
Figure 10. 

II55I The seeo^i step is to define the flows and states in our hierarchic state machine 
model because model cheeking techniques are based on heirachical state machine 
model. TT« BPBMWS specificadon is tnmslat^I into StateML. whieh serves as fl,e 
state fl,ecification tanguage of bod, BPI state and model checking. An algoriflm, is 
developed to do flte tmnslation automaticaBy. This p,«,edute is indica««i by am>w a 
m Figure 10. 

lisq The third step is to abstract the system and requirement ^ification by mapping both 
herarehical state n«>hines and predicates into Ahstmc State Machmes. 
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This step is necessary because the original specification may have too many states or 
even an infinite state space. Model checking on such a state machine will encounter 
state explosion problem. Abstraction simplifies the state space of the original 
specification. This procedure is indicated by arrow c and d in Figure 10. 

1157] The Fourth step is model checking the abstract state machine. The result is then used 
to further refine the state machine models. Steps 3 and 4 are performed iteratively 
until the abstract state machines are successfuUy model checked. This procedure is 
indicated by arrow b, e, and fin Figure 10. 

[158] There are two approaches for abstraction and model checking: Counter-example 
guided and weakest precondition guided. 

[159] In simple, counter-example guided abstraction foUows the foUowing procedure: 

1 . Initially set EO to include predicates in the requirement 

2. Iteratively cany out following steps: 

a. Abstract concrete model with Ei. 

b. Model checking abstract model, if answer is yes. then terminates. 

c. If answer is no, we simulate concrete model and find out new predicate Fi 
which caused the problem. 

d. Let Ei+1 := Fi union Ei and i := i +1, and proceed to next iteration. 
[160] Weakest precondition guided abstraction is summarized is follows: 

1 . Apply requirements predicates to the concrete model. 

2. Backwardly compute weakest precondition for each state based on predicates in step 

3. Abstract concrete model with all predicates computed. 

4. Model checking the abstract model, if answer is yes, then terminate. 

5. If answer is no, modify the abstraction and rerun the model checking. 
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6.6.3 Runtime Monitoring 

[161] Runtime monitoring guarantees the correctness of a running process. Though a 
process is verified at design time, runtime monitoring is still necessary. This is 
because: a) Some properties may not be verifiable in design time due to the 
abstractions; b) some activities may have undeshred runtime properties that are not 
specified in their interface, c) Many performance and security policies have to be 
guaranteed at runtime. 

[162] A runtime monitor is automatically constructed based on the safety property 
requirements formally defined as temporal predicates. The monitor executes in 
parallel with the monitored system at runtime and detects any violations of flxe safety 
properties. Once a violation is detected, the monitor will interrupt ttie current process 
execution and start an error-handle procedure. 

[163] Security is ensured through language based techniques. Each data item in the 
specification is associated wifli a secure type tag, such as high or low, to indicate the 
security level. Each program block is associated with a security context. The model 
checker performs type inference analysis to make sure that information flow is 
consistent with the tagged values of blocks and data items. For example, all 
assignments to a data item tagged low are eitiier derived from low values or take place 
in a low context 



6.7 Automatic synthesis of Business workflows 

[164] A workflow requirement specifies the precondition and the expected postcondition of 
a workflow. A correct workflow specification, if exists, can hopefiiUy be found out 
based on the semantics of a given task library. 

[165] The problem is, given a task library and a workflow requirement, a correct workflow 
specification is generated automatically. 

(1661 To illustrate the problem, suppose we have a task library as described in Figure 5. The 
tasks are components used to build a corporate action workflow. 

[167] It is easy to see that the tasks can not be arbitrarily connected, because the 
postcondition of one may not satisfy the precondition of another. There are a set of 
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basic rules on how to correctly connect the tasks togeflier using the workflow 
constructs. 

[168] Sequence: Suppose a task or workflow A's postcondition implies the precondition of 
task or workflow B, then A and B can be composed m a sequence structure. An 
example is shown in Figure 6. 

1169] Branching: If the output of task A only partially implies the precondition of task B, 
then some output cases from A is not handled by simply forming a sequence of A and 
B. The outputs from' A that are not handled are called dangling edges. If the 
conditions on the dangling edges imply preconditions on other tasks, then a branching 
need to be formed to handle different cases by different tasks. If a set of tasks can be 
found to cover all possible cases from A. then a correct branching constmct can be 
formed. An example is shown in Figure 7. 

(1701 Loop: Sometimes a dangling edge can be fixed by feed it back to some tasks on the 
path and form a loop, which means we retry the sub-workflow inside the loop untU a 
condition is satisfied. An example is shown in Figure 8. 

[171] Exception: Exceptions are just special output edges, so tiiey can be handled the same 
way as branching. The only difference is that they often imply the workflow is in 
some error state, and has to be dealt with separately by error handlers. In addition, 
same exceptions may be generated by different tasks, so that a single handler can be 
used for a group of them. Instead of creating branches, a catch statement is created to 
handle exceptions in a block. 

[172] Subflow: a synthesized workflow can be used as a component to form a larger 
workflow. 

[173] Based on (he construction rules, all possible workflows can be constructed from a task 
library. However, the number can be astronomical and not all of them satisfy the 
business goals. An algorithm is needed to find the right workflow that satisfies given 
business goals. 

1174] The business goals are specified in terms of workflow preconditions and 
postconditions. A workflow needs to be generated such that, suppose the 
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preconditions aie true when the workflow starts, postconditions should be true when 
the workflow finishes. 

(1751 To make the problem tractable, algorithms for special cases of the problem are first 
constructed, and then more general algorithms are built up based on the special cases. 

I176I Casel; Tasks has only positive predicates in preconditions and single oulput in 
postconditions. 

1177] The task library satisfies the followmg assumptions: 

1 . Task precondition is a conjunction of positive predicates. 

2. No variable assignment or conditions on variables are allowed. 

3. Task library follows tiie ranking assumption. (See below) 

4. Initially flie value of all predicates is either true or false. The actual value can not be 
a^ed by the workflow generator The generated workflow has to work conectiy in 
all possible cases. (No workflow precondition is given.) 

11781 Ranking: a partial order relationship < can be defined on the set of predicates PS, and 
the task library TS respects the partial order < in the following sense: 

a. For any task $T$ in $\mathcal{T}$, there exists a positive predicate q_0 in T's 
postcondition. q_0 is caUed primary output. For any predicate p in Ps precondition 
and non-pnmary predicate q in Ts posteondition, we have 

b. p<q_O.q<q_0. 

c. No predicates in $T$'s pie and post conditions have higher rank than $q_0$. A task 
can have more than one primary outputs. 

d. All predicates are primary ou^uts of at least one task. 

[179J Path: A path is a sequence of tasks. Assuming the precondition of tiie first task is 
satisfied, all tasks in the path can be executed correctly in the sequential order. 

Theorem: 

11801 Given a task library that satisfies the ranking assumption, we have the following: 

[1811 For each predicate p, there exists a patii Path(p). Palh(p) makes p true, and p is the 
primary output of (he last task of Pafli(p). 
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Ih^OT^Z,^^ * subworicflow. then p is the primaiy output of the 

b. No predicates with a higher rank than $p$ appears in the path. 

^Ldkate^ of attribute closure to calculate paths that implement the 

[182] Algorithm: Given a library TL. find a workflow for each particular predicate by 
construct the attribute closure of tiie library CL(TL). 

[183] The closure is all the predicates that can be made true. Each predicate $p$ is 
associated with a path attribute, which belongs to Path(p). 

Case 2: Allowing conditions 

[1841 The case follows the same assumption as in Ihe above section, but adds in the 
assmnptions to handle conditions. 

Additional assumptions: 

[185J Task precondition is a conjunction of positive predicates, conditions on single 
variables, such as $x > 0$, or a combination of both. 

a. Predicates in postcondition may be of the form gen(x). If a task postcondition has 
gen(x;, gen(x) must be a primary output, and the only primary output of (hat task. 

b. A variable x is not assigned when the workflow starts, that is, gen(x) = felse initially. 

c. gen(x) and condition on x (x>0) have the same rank. 

{186J Path; A path is a sequence of tasks. There are possibly conditions on variables 
preceding some of the tasks. If the precondition of the first task is satisfied, tasks in 
the path can be executed correctly in the sequential order if we assume conditions 
preceding a task are true when tiie task starts. 

[187] Path(p) is a path with p as the primary output of the last task (and hence the primary 
output of the path). If there is no condition on a path, the path is a complete path. 
Otherwise, the path is a partial path. Conjunction of all the conditions along a path is 
condition of the path. 

[188] Given a task library that satisfies our assumptions, 

[189] For each predicate p, there exists at least one path Path(p). Path(p) can be partial. 
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[190] A task producing geii(x) only needs to appear at most once in a pafli. 

1191] For all variables X={x_l, x_2, x_n} in the task library, gen(x_l), gen(x_n) 
can be sorted into a total order which keeps the partial order of the variables* ranking. 
If there exists a partial path implementing p with conditions along the path C(x_l), 
C(x_2), \ldots, C(x_k), then there exists a partial path implementing p that generates 
each variable at most once and with the same set of conditions annotated on the path 
in the given total order, 

[192] For each variable x_i, we need only one task to generate it. 

Attribute Closure algorithm: 

[193] We only need to find a partial path for each equivalent set according to the order of 
variables. We can achieve fliis by adding the following rules to the closure algorithm. 

[194] Algorithm: construct all partial paths through building the attribute closure. 

[195] Algorithm: Construct a workflow fi-om the closure. 

Case 3 : Multiple primary ou^uts in postconditions 
[196] Additional assumptions: 

[197] A task can have more than one output, each of which is a conjunction of predicates as 
specified in the previous section. If a task T has multiple outputs, then each output has 
one and only one primary predicate. In addition, if p_i, pj are primary predicates of 
Ts outputs, then Rank(pJ) is not higher or lower than Rank(pJ). 

Case 4: Allowing multiple output and negations 
[198] Extending the definition of rank: 

a. Predicates can be arranged in partial order as in the previous section, and the notion of 
rank is extended to negations of predicates. 

b. Rank(p) = Rank(not p). 

c. Rank(p) = Rank(q), p not q -> p = not q. 
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(199] A predicate and its negation have the same rank, and it is the only case that two 
literals have the same rank. 

12001 The model is extended to allow some limited forms of negation in precondition, and 
multiple outputs. 



6.8 BPI Framework based Applications (possible examples but not limited to) 
[2011 The BPI Framework can be used for a wide range of business process automation 
including but not limited to following financial services workflows: 



6.8. 1 Corporate Actions Management 

[202] Managing Corporate Actions Business Process in Custodian and Asset Management 
organizations requires a complex combination of business flows, rules and state 
management. Corporate actions workflow comprises of seven stages, e.g. data 
capture, event certification, entitlement, notification, decision making, account 
posting and settlement as independent modules. It is developed on the BPI framework 
and uses industry standards such as MDDL, SWIFT MT564/5 for data model and 
interfacing with external systems. 

6.8.2 Older Management Systems Integration with Market Data, Portfolio and Compliance 
Applications *^ 

[2031 Traditional Order Management Systems are not well integrated to other financial 
systems such as Market Data. Portfolio and Compliance applications. The BPI 
fiamework provides a suitable way to automate flie integration workflows. 



6.8.3 Data Management System 

(2041 Creating an accurate repository (often known as 'gold copy') of financial data 
requires complex automated and human workflow. Traditionally these business 
workflows and rules are implemented as custom programs, where the ability to 
change the business logic based on maricet demand is an expensive and slow process. 
The BPI Framework provides a way to automate these business processes where 
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business rules can be changed as required without a large impact to the rest of the 
systems. 
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7 SCHEMAS AND EXAMPLE INSTANCES 



7. 1 Schemal : BPDL Schema 

<?xml versions" 1,0" encod±ng=»"utf-16"7> 

// , . targetNameapace»"http: //Reuters. com/BPD" 

xmlns : xs«"http : //wvTw . w3 . org/2001/XMLScheina" 

xmlns :b="http: //schemas .microsoft , com/BizTalk/2003" xmlns : rbf-"http: //Reuters .com/BPD" 

^'^^'^'^^^'^'^^''''^^^f^^^-^^^ elementFormDefault-«qualified" 
attributeFormDefault«"qualified" id="BPD"> 

<xs: include scheiaaLocation«"BPDArtifactDefinition.xsd" id=»"rbf ArtifactDef inition"/> 
<xs:eleiaent name«"BPD'»> 

<xs : complexType> 

<xs:sequence> 

<xs : element name»" Flows > 

<xs : complexType> 

<xs : se(|uence> 

<xs: element name="Flow" minOccijLr3«"0" maxOccurs«"unbounded"> 
<X3 : complexType> 

<xs: group ref «"rbf : rbf ArtifactDefinition"/> 

</xs ; CQmplexType> 

</xs:element> 

</x3 : sequence> 

</x3 : complexType> 

</xs : element> 

<xs: element name='*RuleSets**> 
<xs : complexType> 
<X3 : sequence> 

<xs: element name«"RuleSet" minOcc\irs="0" maxOccurs»" unbounded" > 
<xs : complexType> 

<xs: group ref»"rbf:rbf Artifact Definition" /> 

<xa:attribute name«"MajorRevision" type«"xs :unsignedlnt" use='"optional"/> 

<xs:attribute name»"MinorRevision" type«"xs :un3ignedlnt" us e=«" optional "/> 

</x3 : complexType> 

</xs :element> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

<xa: element nameB"StateModels**> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="StateModel" minOccurs""0" maxOccurs«"unbounded"> 
<xs : complexType> 

<xs : group ref ="rbf : rbf Artifact Definition "/> 

</xs : complexType> 

</xs :eleraent> 

</xs ; sequence> 

</xs : complexType> 

</xs : element> 

<xs : element nanea "Entities "> 
<xs : complexType> 
<xs : sequence> 

<xs: element name="Entity" minOccurs="0" maxOccurs=" unbounded" > 

<xs : complexType> 

<xa : group ref «"rbf: rbf Artifact Definition" /> 

</xs : complexType> 

</x8 :element> 

</xs : sequence> 

</x8 : complexType> 

</xs : element> 

<xs : element nameB"Taxonomie8"> 

<xs : coraplexType> 

<xs:aequence> 

<xs : element name»"RDF"> 

<xs : complexType> 

<xs: sequence minOccurs«=»"0" maxOccurs="\inbounded"> 
<xs: element nameo" Taxonomy" maxOccurs="unbounded"> 
<xs : coinplexType> 
<xa : sequence> 

<xs:any proces3Contents«"skip" minOccurs="0" maxOccurs»"unbounded"/> 

</x3 ; 5equence> 

<xs : attribute namea^name" /> 

</xs : complexType> 

</xs : element> 

</xs : sequence> 

</x8 : co2i^lexType> 
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</x3 : element> 
</xs : seguence> 
</x3 : complexType> 
</xs : element> 

<xs : group ref ="rbf : rbfArtif actDef inition"/> 
<xs : element names " SubBPDs " > 
<xs : complexType> 

<X3: sequence minOccursB^O** maxOccurs***'unbounded**> 
<X8: element namea*'BPD"> 
<xs : complexType> 

<xs : group ref «"rbf : rbf Artlf actDef inition" /> 

</x3 ; complexType> 

</xs :element> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

<xs : element name"" Views '*> 

<xs : complexType> 

<xs: sequence minOccurs«*"0" maxOccurs^" unbounded** > 
<xs: element name«"View"> 
<xs : complexType> 

<xs : group ref ="rbf : rbf Artif actDef inition" /> 

</x3 : complexType> 

</xs : element> 

</xs : sequence> 

</xs : complexType> 

</xs : element> 

</xs : sequence> 

</xs : complexType> 
</xs : element> 
</xs : schema> 
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7.2 XML-Schema specification of the concrete data model of the negotiation piocess 

<xsd: schema Kmlns : xsd=- http : //www , w3 . ora/2 001 /XMI.S nh^,n^ 

targetName3pace=-- http://www,NeaotiatlonML.o7^ 

xmlns==--httpV/www.NeqotlatlonML.nrr^^^ ^^^^ r,^^ - 

<xsd : ComplexType name="Negot iationsType"> quaxiiiea > 

<xsd: element name--negotiation" type="negotiationrype" 
niaxOccurs="unbounded'V> '-^-ype 

</xsd : ComplexType> 

</xsd : ComplexType name="negotiationType"> 

<xsd: element naine=''id'' type="integer'V> 

<xsd: element naiae="CurrentBid" type="bidType'V> 

<xsd: element name="BidHi story" type="bidType" 

minOccurs="0'' inaxOccurs="unbounded"/> 
</xsd: CoinplexType> 
<xsd: ComplexType name="bidrype"> 

<xsd:element name«"id" type=="integer"/> 

<xsd: element name-^'bidder" type="traderType"/> 

<xsd: element name="listener" type="traderType'V> 

<xsd: element name=''details" type="5^ML'V> 
</xsd; ComplexType> 

</xsd:schema> 
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7.3 An instance of tibe Negotiation Data Model 

<Negotiations> 

<Negotiation> 

<Id> 101 </Id> 

<CurrentBid> 

<Id> 1 </Id> 

<bidder> 

<Id> 1 </Id> 

<name> A </name> 

<branch>Nyc</branch> 

<Initiated>NO</Initiated> 

<Agreed> value="NO"></Agreed> 

<Negotiating>NO</Negotiating> 

<Confi3nned>N0 </Confinned> 

</bidder> 

<listener> 
. <Id> 2 </Id> 

<name> B </name> 

<branch>L0NDON</branch> 

<Initiated>NO</Initiated> 

<Agreed> value="NO"></Agreed> 

<Negotiating>NO</Negotiating> 

<Confirmed>NO </Conf irnied> 

</listener> 

</CurrentBid> 

<BidHistory> 

</BidHistoxy> 
</Negotiation> 
</Negotiations> 



SO 



wo 2004/114061 



PCTAJS2004/018435 



7.4 Example of high-level data model 



<property nanie="SingleConf irmed" expression=" 
(negotiation/CurrentBid/bidder/confirmed = yes) xor 
(negotiation/CurrentBid/listener/confirmed « yes'V> 

<property name=" Double Con firmed" value=" 
(negotiation/CurrentBid/bidder/confirmed yes) and 
(negotiation/CurrentBid/listener/confirmed = yes"/> 



[205] Aspects of the present invention have been described in terms of illustrative 
embodiments thereof. Numerous other embodiments, modifications and variations 
within the scope and spirit of the appended claims will occur to persons of ordinary 
skill in the art from a review of this disclosure. 
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9 BACKGROUhTO OF THE INVENTION 

A process and system for automating business functions is described. 
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